home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950528-19950726 / 000244_news@columbia.edu_Thu Jun 29 16:41:56 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27745
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Thu, 29 Jun 1995 15:16:14 -0400
  3. Received: by apakabar.cc.columbia.edu id AA20020
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 29 Jun 1995 15:16:12 -0400
  5. Newsgroups: comp.protocols.kermit.misc
  6. Path: news.columbia.edu!panix!tinman.dev.prodigy.com!prodigy.com!newsjunkie.ans.net!howland.reston.ans.net!ix.netcom.com!netcom.com!jhurwit
  7. From: jhurwit@netcom.com (Jeffrey Hurwit)
  8. Subject: Re: Configurable APC checking in next MSK release?
  9. Message-Id: <jhurwitDAy11x.7Jq@netcom.com>
  10. Organization: Organization?  What organization?
  11. X-Newsreader: TIN [UNIX 1.3 950520BETA PL0]
  12. References: <jhurwitDAuowt.ICo@netcom.com> <1995Jun29.071144.54932@cc.usu.edu>
  13. Date: Thu, 29 Jun 1995 16:41:56 GMT
  14. Lines: 54
  15. Sender: jhurwit@netcom11.netcom.com
  16. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  17.  
  18.     Thanks to both Frank and Joe for your comments.
  19.  
  20. In article <1995Jun29.071144.54932@cc.usu.edu>,
  21. Joe Doupnik (jrd@cc.usu.edu) wrote:
  22.  
  23. >    The reason OUTPUT is on the dangerous list is this. Something
  24. >on the host sends APC OUTPUT \26DEL *.* ST to your desktop machine. That's
  25. >includes a form of nasty mail trouble (^Z to suspend currrent process,
  26.             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  27. >start removing files).
  28.  
  29.     Hmmm, I see your point.  I can see some visciousness on the part of
  30.     someone (similar to ANSI bombs, right?  Someone would have to know
  31.     that I'm using Kermit), but I'm not familiar with the kinds of
  32.     system vagarities that would accidently trigger an unwanted APC
  33.     command that would in turn cause damage on the host account.  I'll
  34.     take your word for it!
  35.  
  36. >    I'm not sure we want to itemize commands which are dangerous
  37. >because it is a bulky operation in the program and it adds to the doc
  38. >complexity (must now explain how each candidate can be abused remotely
  39. >etc).
  40.  
  41.     I didn't know it would bloat the program that much.  Having only
  42.     recently stepped up from an 8088 portable with no hard drive, I
  43.     really appreciate your continuing to support antiquated equipment
  44.     with minimal resources!
  45.  
  46.     Ok, then let me try this suggestion:  Currently, MSK will ignore a
  47.     'set apc unchecked' command in a script or macro if it was invoked
  48.     with an APC command.  How about reversing this so that MSK will
  49.     recognize and act on that command?  What I envision is placing a
  50.     'set apc unchecked' just before a dangerous command, and 'set apc
  51.     on' just after.  This way, the window of opportunity for a system
  52.     burp setting off an unwanted command would be small, and an "APC
  53.     bomb" in an e-mail message could do nothing at all without knowing
  54.     the name of the script or macro.
  55.  
  56.     In fact, better yet, how about an "unchecked' command, to be used
  57.     only in scripts or macros?  Placed just before the dangerous
  58.     command (eg. 'uncheked output xxxx'), it could disable APC checking
  59.     just for the duration of that command, and reestablish it
  60.     immediately afterward.
  61.  
  62.     For the docs, you could simply list out the commands which are
  63.     checked, following a brief and general discussion of the reasons
  64.     for checking them.  More than that would not be necessary if the
  65.     user has the option of an 'unchecked' command.
  66.  
  67.     How does this sound?  Would it add too much to the size and
  68.     complexity of MSK?  I think it could provide a good balance between
  69.     safety and flexibility if properly used.
  70.  
  71.                                         Jeff